Thank you for your pull request. It looks like this may be your first contribution to a jQuery Foundation project, if so we need you to sign our Contributor License Agreement (CLA).

📝 Please visit http://contribute.jquery.org/CLA/ to sign.

After you signed, the PR is checked again automatically after a minute. If there's still an issue, please reply here to let us know.

If you've already signed our CLA, it's possible your git author information doesn't match your CLA signature (both your name and email have to match), for more information, check the status of your CLA check.

Why are you saying that ID and class selectors aren't very fast? jQuery takes advantage of native methods when using those selectors which makes it very fast.

This PR is about filtering by selector, for example $('...').on('click', '.myClass', func), not about just $('...').

I have tested it on jQuery 1.11.0 and 3.1.0. When I adding 100k listeners with '.class' selector every trigger calling takes more than 6 second in Firefox!

Well, somebody can say that 100k is too much but 1000 listeners is usual case and it lags for 60 msec every mouse click. On the mobile phones it can lag about 1 second. They are very slow.

ID selectors work faster but only 5 times faster and still very slow.

Do you need the tests?

When I reimplemented standart $.fn.on it began to work 3000 times faster when calling trigger with 100k listeners filtered by class selector (and this is using original $.fn.on for compatibility with $.fn.trigger). Listeners adding is faster too. My implementation breaks calling orders but I don't need it at all.

Even with 1000 listeners my implementation works 30 times faster, 9 times faster with 100 listeners and 2 times faster with 10 listeners.

3000 times slower than very simple implementation is too bad.

Those are very unrealistic tests. Most elements have only one or two event listeners on them. Thousands on a single element would be a sign of something seriously wrong with the way the developer has designed their application. Just the extra memory we use to track events would become significant at that point.

I don't think 1000 listeners with filtering by selectors on one elements is bad. I have one-page application with autogenerated content and it is normal. Actually I have 200 listeners but even 200 listeners are very laggy on mobile phones.

Memory is not issue. When I reimplemented it 1000 listeners use about 50 KB memory. Issue is your bad implementation. And this PR is about bad place in the documentation. I don't mind bad implementation but it should be documentated properly.

My PR fixes bad place in the documentation and it'll be great if you merge it.

@dmethvin, I checked jQuery, it doesn't use much memory too. May be you mean listeners without filtering? I'm saying about filtering events by selectors, not just events.

@vitaliylag if you think there is something wrong with the implementation, you should open an issue and perhaps submit a PR to fix it. I agree with @dmethvin that adding 1000 listeners to an element sounds like a crazy idea and that a test where you add 100k listeners to an element doesn't match any real use-case scenario.

«1000 listeners sounds like a crazy idea» — it's not crazy idea, in my one-page application I have 200 listeners and it's not much.

@AurelioDeRosa, I have opened issue with the description of fast algorithm keeping calling order jquery/jquery#3254, but that doesn't mean that documentation shouldn't be improved.